Support of Asynchrony in Sensor Web

Sensor Web is a system of systems, of which each system consist of live sensor, data, and geospatial processing services. In a broad sense, it includes archived data, and ondemand generated data or virtual sensor. In such a system, asynchrony cannot be avoided because of differences in clock/time and the long processing time of complex processes. Asynchrony can occur at the sensor planning stage, the data collection phase, or in the data processing process. Support of asynchrony is one of the core characteristics of the Coordination and Event Notification Services (CENS), the central component of the Self-Adaptive Earth Predictive System (SEPS) that operates Sensor Webs. This paper reviews the different types of asynchrony in the Sensor Web system and their technical solutions. Technologies in industry to support asynchronous mechanisms can be roughly grouped into two major categories: message queuing and publish-subscribe. Representative technologies include Web Services Addressing (WS-Addressing) for message queuing and the Extensible Messaging and Presence Protocol (XMPP) for publication-subscription. In emerging geospatial standards, the Web Notification Service (WNS) and the Sensor Alert Service (SAS) are designed to deal with asynchronies at message queuing pattern and publish-subscribe pattern correspondingly. There are generally two approaches in coordinating collaborative work by systems of systems. They are orchestration and choreography. Orchestration has a central director to guide the execution of each step such as a workflow. Choreography is a bottom-up approach, in which coordination is achieved by defining each individual web service/resource. In this project, orchestration is used. Business Process Execution Language is adopted as the script language to describe the composite processes. No matter which approach is chosen, a complex composite process involves syndication of all services and data as the final outcome. The syndication introduces problems similar to those, such as deadlock and reachability, encountered when trying to synchronize asynchronous threads in multi-thread programming. To solve these problems, proper methods for handling asynchrony in the Sensor Web system are crucial. With the acceptance of the Representation State Transfer (REST), the new style for Web Service, a new paradigm, called Resource Oriented Architecture (ROA), has emerged for interoperation in the Web environment. ROA is different from Service Oriented Architecture (SOA) in many aspects. Mechanisms for supporting asynchrony, e.g. HTTPEvents, are also emerging. Workflow standards specifically dealing with RESTful services, e.g. WfXML are emerging as well. Asynchronous prototypes for both resourcefocused and service-focused workflows have been examined and demonstrated in two scenarios in this project. One is a wild fire workflow and another is the georeferencing workflow. Open research issues are also pointed out, especially those to be studied in the emerging Web 3.0.